Telecommunication network operators are often reluctant to open their networks to new companies that offer communication-based applications. Their reluctance is at least somewhat justified in that network operators risk cannibalizing their own applications, particularly if price becomes the major difference between their applications and those offered by new companies. In fact, telecommunication network operators risk becoming mere ‘transporters of bits’ if they cannot compete with applications offered by new companies having low overhead costs.
Additionally, if telecommunication network operators open their networks to new applications and companies, network operators facing losing control of their networks by having to support network demands driven by applications written and maintained by 3rd parties, such as service providers or software vendors.
While the reluctance to open their networks may be justified, if telecommunication network operators do not do so they risk losing lucrative markets that new companies and applications might create. Since most new companies operate outside of the traditional telecommunication network boundaries, new applications may create entirely new services that bring in customers that normally would not use the network. Additionally, government mandated forces that seek to increase telecom market competition can force network operators to open their networks.
In one scenario, transactions between a network and applications are beneficially based on a set of interfaces and data types that form Application Programming Interfaces (APIs). If those APIs are standardized and widely available for use, such APIs are referred to as open APIs. Open APIs are typically established by software organizations that both carefully define the APIs and promulgate their use. Many sets of open APIs exist, for example the Parlay/OSA APIs, which were originally defined within the Parlay group and standardized in the context of 3GPP and ETSI. The Parlay/OSA APIs (where OSA stands for Open Service Architecture) form a set of nine orthogonal Service Capability Functions (SCFs), each of which address a different telecom area: call control, user interaction, mobility, terminal capabilities, data session control, generic messaging, connectivity management, presence/availability, and charging.
Thus, a prior art API-based system includes a set of open APIs, a set of users that send and receive information via servers, a telecommunication network that transports the information, and 3rd party-owned applications that receive information through the open APIs, runs an application based on those APIs, and sends responding information back to the network through the open APIs.
While useful, prior art API based systems are subject to significant limitations. First, in prior art API-based systems there is a one-to-one relationship between open API servers and applications. To overcome this limitation, prior art API based systems have included a Registration and Discovery entity that is used by the Open API servers to announce themselves and used by the applications to discover what APIs are available. When there are multiple Registration and Discovery entities, a fundamental problem is what registration and discovery entity an Open API server should use. To avoid that problem an Open API server could announce itself to all of the available Registration and Discovery entities. But, that creates a problem since to assign an open API server to multiple registration and discovery entities, the configuration of the overall system must be known, and that is difficult to determine.
Another problem in prior art API based systems is after an application discovers what open API server to use for its services, that relationship is static. While the initial open API server might have been beneficial at a certain moment in time, a subsequent occurrence, such as an Open API server failure, could create huge problems. In that case, the application providing a certain service could no longer be used without a recovery session that was initiated by the application. Yet another problem in prior art open API systems is the difficulty of enforcing Service Level Agreements.
In view of the foregoing (and other) limitations, a new open API-based system has been proposed. That system includes open applications and open API servers, but the telecommunications network inserts a proxy device between the open applications and the open API servers. That proxy can handle start-up to avoid overlap, determine which open API server (or servers) will handle a particular API event or method invocation, balance communication loads between the various open applications and open API servers, and dispatch events between the open applications and open API servers.
While the proxy is a promising addition to open API-based systems, the proposed proxy fails to address other foreseeable problems in successful systems. Therefore, a proxy that addresses other problems in open API-based system would be beneficial. Also beneficial would be a telecommunication network having a proxy that addresses other problems of open API-based system. In addition, a method of operating a proxy that addresses other problems of open API-based system would be beneficial. A computer readable media that stores a computer program that operates a proxy that addresses other problems of open API-based system would also be beneficial.